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(57) Abstract: A system and method for 
monitoring patient variables in a wireless 
manner via a patient worn monitoring 
device is disclosed. The patient monitoring 
device is wearable and connects to a 
variety of sensors (32, 34, 35, 36) and 
at least one microphone (60) for voice 
communications. The device connects to a 
wireless network and thence to the Internet 
for transmitting data to a Host for access 
by a medical care provider. The medical 
care provider communicates with the 
patient- wearable device via the Internet and 
the wireless network to send instructions 
to the patient-wearable monitoring unit and 
to communicate via voice with the patient 
The medical care provider can also flexibly 
reconfigure (54) the device to change 
collection parameters. When an alarm limit 
is exceeded as detected by the sensors (32, 
34, 35, 36), the data are transmitted to the 
Host computer for use by the medical care 
provider, thereby allowing full mobility to 
the patient wearing the device. 
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1 TITLE: WIRELESS INTERNET BIO-TELEMETRY MONITORING SYSTEM AND 

2 INTERFACE 
3 

4 FIELD OF THE INVENTION 

5 This invention relates generally to medical monitoring devices. More particularly the 

6 present invention is a system and method for monitoring physiologic, biochemical or 

7 biometric variables of an individual in a wireless mode over the Internet. 
8 

9 BACKGROUND OF THE INVENTION 

10 Monitoring devices of various types to monitor patient physiologic, biochemical or 

1 1 biometric variables have long been used by the medical community. A plethora of testing 

12 and monitoring equipment has moved out of the hospital into the doctors' offices and, in 

13 some cases, these systems have even progressed into home monitoring systems. 

14 While these devices have clearly been extremely useful, many of these devices 



1 5 require that a patient be located at home, or in close proximity to a telephone system such that 

16 results of the monitoring can be transmitted over the Public Switched Telephone Network 

17 (PSTN) to some form of analysis center. Such devices do not necessarily lend themselves to 

1 8 the mobile life style in which many individuals find themselves. 

19 For example, it is difficult for a busy person to stop in the middle of the day, proceed 

20 to a monitoring station, whether in a home or in some office, take the appropriate 

21 measurements, and then proceed with the business of the day. This is simply not possible and 

22 adds a level of stress to the already stressful situation of having to monitor physiologic, 

23 biochemical or biometric signals. For a seriously ill person, it is often very difficult for the 

24 person to move to a personal computer or to attach a monitor to a connection to the PSTN 

25 system. 

26 What would truly be useful is a system for monitoring physiologic, biochemical or 

27 biometric characteristics of an individual on a mobile basis. Such a system would require 

28 little, if any, interaction with a monitoring device. Signals that are collected would then be 

29 sent in an automated manner to an analysis center or a physician's office. Alternatively, a 

30 physician could interrogate the system worn by a patient while the patient is mobile to obtain 

3 1 the physiologic signals of interest or create changeable automatic signal acquisition protocols 

32 depending on the patient's condition. Additionally, if more appropriate in a particular clinical 

33 setting, the patient could initiate sending of a signal to the physician. 
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1 

2 SUMMARY OF THE INVENTION 

3 It is therefore an objective of the present invention to remotely monitor physiologic, 

4 biochemical, or biometric variables from any patient. 

5 It is a further objective of the present invention to monitor physiologic, biochemical, 

6 or biometric variables of a patient whether the patient is ambulatory or stationary when the 

7 health care provider is remote from the patient. 

8 It is yet another objective of the present invention to monitor physiologic, 

9 biochemical or biometric variables using the Internet. 

10 It is still another objective of the present invention to monitor physiologic variables in 

1 1 conjunction with a wireless communication device such as a cellular telephone. . 

12 It is a further objective of the present invention to monitor physiologic variables in a 

13 wireless manner within a generalized geographic area. 

14 It is a further objective of the present invention to monitor physiologic variables 

15 without the patient having to proceed to any centralized location in a geographic area. 

16 It is a further objective of the present invention to monitor a patient anywhere in the 

17 coverage map of a cellular- or satellite-based telephone network. 

18 It is a further objective of the present invention to have data relating to physiologic 

19 variables automatically sent over a wireless network to a physician or other medical caregiver 

20 using the Internet. 

21 It is a further objective of the present invention to allow a health care provider to 

22 interrogate the physiologic monitoring device in a wireless fashion using prescribed protocols 

23 or ad hoc queries whenever the health care provider needs to take such physiologic 

24 measurements. 

25 It is a further objective of the present invention to provide voice communications in a 

26 wireless mode to and from a user and a medical caregiver. 

27 It is yet another objective of the present invention to provide voice communications 

28 through a cellular telephone between a user and a medical caregiver. 

29 It is still another objective of the present invention to provide two-way messaging 

30 between a user and a medical caregiver. 

31 It is yet another objective of the present invention to detect a persistent out of range 

32 physiologic, biochemical or biometric measurement and to issue an alarm signal to the patient 

33 and health care provider. 

2 
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1 It is a further objective of the present invention to have a "panic" function which 

2 allows both a user to send a "panic" message to a health care provider or allows a health care 

3 provider, after monitoring physiologic signals, to send a voice "advice" message or text- 

4 based instructions to the patient. 

5 It is still another objective of the present invention to provide automatic testing and 

6 troubleshooting functions for the physiological monitoring device. 

7 It is a further objective of the present invention to accomplish all the above objectives 

8 using a device that is worn by the patient in a relatively unobtrusive fashion. 

9 These and other objectives of the present invention will become apparent to those 

10 skilled in the art from a review of the specification that follows. The words physician, 

1 1 doctor, healthcare provider, caregiver, medical care provider, care provider, etc. as used 

12 herein shall mean the person with the responsibility for the care of the patient. 

1 3 The present invention is a Wireless Internet Bio-telemetry Monitoring System 



14 (WDBMS). The system makes use of a variety of physiological, biometric and biochemical 

15 sensors and measurement systems that are generally used to detect signals or measure 

16 variables directly from the human body or from biological fluids such as blood or urine. One 

17 such sensor system is described in US Patent 5,673,692 whose characteristics are 

1 8 incorporated herein by reference in their entirety. However, this particular sensor is not 

19 meant as a limitation. Literally any type of bio-sensor or physical sensor generally known to 

20 those skilled in the art will find use in the present invention. Further, the sensor of U.S. 

21 Patent 5,673,692 can include a microphone so that the voice of the patient can be transmitted 

22 using the system of the present invention. 

23 The physiological, biochemical, or biometric sensors are connected to a combination 

24 data acquisition module and wireless transceiver that is worn by the patient or placed 

25 conveniently near the patient. This combination sensor package and communication unit is 

26 known as the Portable Data Monitor, or PDM. The PDM can monitor many patient variables 

27 at once. The PDM is battery-powered and may operate connected to an external power 

28 adapter. The batteries that power the PDM can be single-use batteries or rechargeable 

29 batteries. Further, when the individual is in a mobile state, the batteries of the PDM, if 

30 rechargeable, can be recharged by plugging them into a car power outlet or into a normal AC 

3 1 outlet. This allows the individual to keep batteries constantly charged in the PDM whether 

32 the individual is mobile or in an office. 



3 
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1 As noted above, the PDM is a patient-worn or patient carried (i.e., patient-wearable) 

2 device that allows maximum mobility to the particular patient. 

3 The PDM has the ability, on a periodic basis, to interrogate physiological, 

4 biochemical and biometric sensors or measurement systems worn or located near the patient 

5 and to store signals from the physiologic, biochemical and biometric sensors or measurement 

6 systems. As required, in response to a physician query, on a periodic basis dictated by a 

7 protocol maintained on an internet Host, or a patient action, the PDM calls into a wireless 

8 network and transmits the bio-sensor information to the wireless network. The bio-sensor 

9 information then proceeds from the wireless network to the Internet and then to the Host, 

10 such as an analysis center or a data warehouse which receives and stores the information for 

1 1 subsequent analysis. In another embodiment, the PDM can be plugged into a cell phone or 

12 computer, adding the capabilities of such devices to those of the PDM. The PDM also 

1 3 comprises an emergency "panic" button whereby a patient can direct the transceiver portion 

14 of the PDM automatically to call 91 1 or a designated medical caregiver in the event of a 

15 medical emergency. 

16 As noted above, the PDM is connected to various physiologic, biochemical and 

1 7 biometric sensors and measurement systems. Therefore, the PDM has sensor condition 

18 detection circuitry, connected to a lamp and/or a message display, which allows a user to 

1 9 determine that all sensors are operating correctly. When a sensor receives a particular signal 

20 out of the normal physiologic range for the particular patient and the out of range 

21 measurement is persistent, a sound and light alarm can be actuated such that the caregiver can 

22 understand that a significant medical event is occurring. The patient is also notified that an 

23 alarm condition is present. Simultaneously with such an alarm, a time-tagged record is 

24 recorded for subsequent retrieval and analysis. 



25 Thus, when the PDM is functioning in a data acquisition mode, it receives 

26 information from the sensors, performs some limited analysis on that information and notifies 

27 the patient and caregiver of any non-standard conditions. 

28 When the PDM periodically sends stored signals from the biosensor over the network, 

29 a unique identifier is encoded with any such data that is sent such that the data can be directly 

30 associated with a particular patient. The data and patient identity are secured. 

3 1 Once data is received at the server, the data is stored with appropriate privacy and 

32 security issues dealt with in a manner known to those skilled in the art. 
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1 The PDM also comprises circuitry for self-testing its various sub-systems and sensors 

2 and for communicating any trouble shooting information directly to the patient in the event 

3 that the sensor becomes dislodged, for example. Further, such trouble-shooting data can also 

4 be sent in a wireless mode to the central server such that trouble-shooting can take place 

5 remotely, or in the alternative, a new PDM unit can be sent to the patient. The patient may 

6 further connect the PDM to a personal computer (PC) for advanced servicing performed by a 

7 technician at a remote location. 

8 The PDM also can be preset before giving it to a patient. In addition, and depending 

9 upon the biological signals being monitored, alarms can be set remotely by the health care 

10 provider over the Internet and subsequently via the wireless network and can be based upon 

1 1 the caregiver's knowledge of the condition of the patient. Such remote setting also occurs via 

12 the two-way communication of the transceiver portion of the PDM. 

13 Communication rates of the WIBMS are optimized to fit common cellular calling and 

14 rate plans and to minimize the cost and air-time usage. 

15 With the WIBMS, the following types of monitoring can take place: 

16 • digitally sampled electrocardiogram 

17 • patient body temperature 

18 • pulse oximetry 

19 • pulse rate 

20 • other physiologic, biometric, or biochemical variables, such as blood glucose, 

21 respiration, weight, etc. 

22 • various pre set alarm conditions or physiologic variables 

23 • event occurrences per patient action/input. 

24 As also noted above the PDM has bi-directional communication capability and has the 

25 capability to transmit "panic" signal over wireless or cellular network, to initiate 911 calls, to 

26 allow a patient-initiated voice calling over a cellular telephone link, and to allow medical 

27 provider voice calling to the patient over a cellular telephone link. 

28 Other characteristics of the present invention will become apparent to those skilled in 

29 the art by review of the detailed description of the invention that follows. 
30 

31 
32 

33 BRIEF DESCRIPTION OF THE FIGURES 

5 
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1 Figure 1A illustrates one configuration of the Wireless Internet Bio-Telemetry 

2 Monitoring System (WIBMS). 

3 Figure IB illustrates an alternative configuration of the Wireless Internet Bio- 

4 telemetry Monitoring System (WIBMS). 

5 Figure 2 illustrates the multi-variable patient monitoring portion of the WIBMS 

6 Figure 3 illustrates the portable data monitor operational mode state transition model. 

7 Figure 4 illustrates a front panel drawing of the Portable Data Monitor. 

8 Figure 5 illustrates the architecture of the Portable Data Monitor. 

9 Figure 6 illustrates a touchscreen of an alternative front panel of the Portable Data 

10 Monitor. 

1 1 Figure 7 illustrates a schematic diagram of a preferred SIICM of the present 

12 invention. 
13 

14 DETAILED DESCRIPTION OF THE INVENTION 

15 As noted above, the present invention is a Wireless Internet Bio-telemetry Monitoring 



16 System comprising a patient monitoring device which is conveniently worn or used by a 

1 7 patient and which interfaces with sensors together with a combination network that allows 

18 biologic signals or measurements to be reviewed and acted upon by a health care provider 

19 who is located remotely from the patient. Data from the monitoring system is sent in a 

20 wireless mode over a cellular network to the Internet, and then to a data analysis center 

21 (Host) for retrieval and review by a medical care provider. 

22 In Figure 1A, one embodiment of the Wireless Internet Bio-telemetry Monitoring 

23 System (WIBMS) is illustrated. Patient 10 wears a multi-variable portable data monitor 

24 (PDM) 12A. This PDM monitors a variety of physiological signals of a patient as further 

25 noted below. The PDM 12A has the capability of communicating bi-directionally via voice 

26 14 in much the same manner as a normal cellular telephone. In addition, the PDM 12A sends 

27 data 16 on a periodic basis, or in some cases on a continuous real-time basis, over a wireless 

28 network to the Internet and then to a Host as well as receives requests for data 18 which may 

29 be made by a medical care provider over the Internet using wireless, PSTN, or alternative 

30 connections to the Host. The PDM 12A sends and receives data with or without use of the 

3 1 voice communication capability of the device. Alternatively, as in Figure IB, a cellular 

32 telephone 11 can further be plugged into the PDM 12B to replace the CDMA module 56 as 

33 shown in Figure 2. 

6 
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1 Wireless network 20 is the normal cellular telephone network currently in use. This 

2 type of network is not however meant as a limitation. For example PCS networks and other 

3 types of wireless loop networks are also suitable for transmission of the voice and data 

4 envisioned by the present invention. It will be apparent to those skilled in the art that such 

5 other networks can satisfy the requirements for transmission of voice 14, data 16, and request 

6 for data 18 to and from patient 10. 

7 Once physiologic, biochemical or biometric data are transmitted over network 20, 

8 they are then transmitted via an Internetworking Function (IWF)® 24, for example, to 

9 preferably the Internet 26 for subsequent communication over the Internet 26 to the Host 30 

10 for retrieval and review by the medical care provider 28. In addition, data can be archived 

1 1 again via the Internet 26 to a data archiving and distribution facility or Host 30. Data that is 

12 archived is stored in a private and secure fashion using techniques known in the art that allow 

1 3 secure transmission and access limitation. 

14 In the event that voice traffic is being transmitted from the patient, a wireless network 

15 20 connects to the public switched telephone network 22 that connects to the medical care 

16 provider 28 or 91 1 operator 32. Again, in this fashion, the medical care provider 28 can 

17 receive voice information from the patient 10 and provide voice feedback to the patient 10 as 

18 well. Similarly, the medical care provider 28 can both receive traffic from the WIBMS as 

19 well as transmit requests for data over Internet 26 through IWF 24 over the wireless network 

20 20 through the Internet 26 via the data repository/Host to the PDM 12A, 12B as well as 

21 configure 19 the PDM 12A, 12B. 

22 The PDM 12A, 12B further provides audio, voice and text messaging capabilities. 

23 Voice messaging typically is short segment phrases, typically of two-second duration. 

24 Audio/voice messaging from the PDM 12A, 12B usually arises as the result of alarms and 

25 alerts detected and reported to the internal system status. There are some special occurrences 

26 such as when the patient instigates a local voice call. As such, messages will be presented to 

27 guide and inform the patient as to the call status. 

28 When audio messages arise because of alarms/alerts reported by the internal status, it 

29 is desirable to repeat the messages until the error is resolved. This can be complicated when 

30 several are pending concurrently. Presenting distinctive sound patterns (for instance, a two- 

3 1 tone sequence) may relieve this in lieu of voice phrasing that can be intuitively associated 

32 with a particular error. • 
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1 Two-way ext messaging between the PDM and the Host is typically provided via a 

2 touchscreen on the PDM and can be used for various purposes, as discussed later in reference 

3 to figure 6. 

4 To further manage concurrent message situations, priority is given to each message 



5 according to the nature of the message. Messaging uses considerable battery power. Thus, 

6 audio message management is important for efficient use of the PDM power supply. Alarms 

7 have top priority. For situations where there are multiple alarms active, then the sequence 

8 can be configured to further set priority by the type of alarm, or create a timing cycle which 

9 displays each alarm for a short time period. Messages are displayed for a Low Battery 

10 Condition, Non-Recoverable Alerts, Voice Call guidance, and Recoverable Alerts (such as a 

1 1 sensor disconnection). Priority can also be set to manage multiple message situations for 

12 these types of messages. 

13 All data that is received from the PDM 12 A, 12B and the network is archived 30 so 

14 that the data from the specific patient can be monitored over time and analyzed for trends that 

15 can be used for alarm setting and data collection protocols. All such data is transmitted in an 

1 6 encrypted form with limited access using methods known in the art so that patent privacy and 

17 confidentiality is maintained. 

1 8 In Figure 2, the PDM is further illustrated. The PDM (initially noted as 12A in 

19 Figure 1 and 12B in Figure IB) comprises, without limitation, a number of biosensors. For 

20 example, blood oxygen saturation level 32, pulse rate 34, electrocardiogram (ECG) 35, and 

21 body temperature 36 can all be measured by physiological sensors associated with the 

22 appropriate measurement. Signals from the sensors are picked up and stored by the data 

23 acquisition module 42. This information from the biosensors is then sent as sensor signals 44 

24 to the CDMA (although other protocols may also be used) module 56 of the PDM 12 A for 

25 subsequent transmission. Alternatively, these signals can be sent by PDM 12B directly to the 

26 cellular telephone 11 as shown in Figure IB. 

27 In addition to simply acquiring data, the data acquisition module 42 also notes any 

28 alarm condition 45 or alert condition 47 and transmits that information via CDMA module 56 

29 or cellular telephone 11 to the Internet, where it can be accessed by medical care providers. 

30 In addition, data acquisition module 42 transmits the time of day 48 with any transmission of 

3 1 alarm information, alert information or sensor information. As noted earlier, the various 

32 alarm and alert conditions can be reconfigured by the health care provider over the Internet 

33 and the wireless network without any patient interaction. 

8 
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1 The CDMA module 56 is, for example, one manufactured by Qualcomm for use as a 

2 cellular telephone module. The CDMA module 56 or cellular telephone 11, in connection 

3 with 3Com "Quick Connect" Internet connection software and 3Com Internetworking 

4 Function (I WF) device are all used to connect to, for example, the Sprint digital cellular 

5 telephone network. The characteristics of the Qualcomm CDMA cellular phone module, the 

6 3Com Quick Connect Internet connection software, and the 3Com Internetworking Function 

7 device are all incorporated herein by reference in their entirety. 

8 The CDMA module 56 or cellular telephone 11 currently allows for digital cellular 

9 communications at 14.4 kbps, which is sufficient for the transmission of the physiological, 

10 biochemical and biometric information contemplated by the present invention. This is not 

1 1 however meant as a limitation as further faster wireless modulated speeds will become 

12 available. All of these faster connections will be suitable for transmission of the data and 

1 3 voice of the present invention. 



14 The PDM can communicate using any of three platforms of communication operation. 

15 These platforms are: CDMA Periodic Post, CDMA Host Request, and RS232 Slave Request. 

16 Only one platform operates at a given time. Data supplied by the PDM over these platforms 

17 may be a one-time snapshot, a sequence of various data, or a chain of real-time data. 

18 In the CDMA periodic post communication, the PDM initiates a Quick Net Connect 

1 9 (QNC) call to establish connection to the Internet with Sprint-PCS as the Internet service 

20 provider (ISP). The PDM makes connection and validation to a Host website and posts data to 

21 an assigned server page in the Host system. 

22 Profiles are stored at the PDM in non-volatile memory. Each profile contains multiple 



23 parameters, one of which determines how often the PDM is to initiate a CDMA network 

24 connection to a specific website Host and post information to it. The specific types of data to 

25 be posted to the Website are also determined by information within the profiles. Various types 

26 of posting data may each be directed to specific web pages of the Host. The PDM post may 

27 contain zero or one piece of data. Each post is a separate transaction. The PDM waits for a 

28 response from each post transaction. The response may be a positive acknowledgment, ACK, 

29 or a negative, NAK. Host responses, posted at the Host in response to each PDM post 

30 transaction may contain additional information beyond an ACK or NAK. The situation where 

31 no data is posted is a mechanism where the Host can subsequently make a request to the PDM 

32 for a null data post in its response. 

9 
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1 If more information is required, the Host will respond with and ACK+MORE message. 

2 This type of response alerts the PDM to seek Host requests on the assigned server page. If no 

3 more information is required and the post was successful, an ACK+NULL response is given. 

4 If more data is required, the PDM responds to the additional Host requests before reverting 

5 back to its original list of post items. If the last post results in an ACK+NULL, the PDM 

6 CDMA connection is ended. 

7 If a NAK is the response to the PDM post, the PDM tries to post the data a 

8 predetermined number of times until the post is successful or until the number of tries is 

9 exhausted. If the PDM was unsuccessful in its post attempts, it pauses for a predetermined 

10 length of time as defined in the profile in effect and then tries to post anew. A NAK may also 

1 1 be accompanied with an error reason. There is logic in the PDM to interrupt the error reason 

12 and take appropriate action. For example, insufficient CDMA signal error will result in the 

1 3 termination of the current post attempt. 

14 The second communication platform used by the PDM is a CDMA Host Request. A 

1 5 CDMA Host Request is performed by a Host making the data request of a specific PDM. A 

16 Host is any web site server capable of uploading profiles and operational parameters to the 

17 PDM. Some Hosts will download and store patient data. Other Hosts may be used to service 

1 8 the PDM remotely. The Host initiates a CDMA voice call to a specific PDM. The PDM is 

19 awakened by the incoming ring. The patient is not initially alerted to the incoming call. The 

20 PDM responds as follows. First, it reads the incoming caller ID, if available, and determines if 

21 it is coming from a known Host or from a voice originating point. If the call is from a voice 

22 origination point, then the PDM logs the originating point as a CDMA voice call, alerts the 

23 patient by allowing the handset to ring and the patient answers the call. 

24 If the call is from a specific data origination point Host, then the PDM waits for the 

25 Host Site to finish ringing and then rings back to initiate a CDMA QNC network connection 

26 with the Host website.Because the Host has originated the sequence, it must now make 

27 available an active server page, which contains an Internet address containing a table of 

28 requests that are expected to be serviced by the PDM. This table of request page is called the 

29 Active Request Page (ARP). The duty of the PDM is to go to the Active Request Page and 

30 sequentially service the requests found at the page. For instance, the PDM may be requested 

31 to provide the user's temperature, SP02, pulse rate, beat-to-beat variability, and single lead 
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1 ECG reading. On completion of all requests, the PDM terminates the CDMA network 

2 connection. 

3 An alternative method for the Host to initiate a request is for the Host to make a CDMA 

4 call to the PDM, and then hang up. There is no check of the caller ID. The PDM initiates a 

5 post to the Host web site with no data. The Host responds with an ACK+MORE which signals 

6 the PDM that requests are outstanding. The PDM then queries the Host for the active request 

7 page, (ARP). The PDM connects to ARP, retrieving the Host requests. 

8 The third communication platform is the RS232 Slave Request. With this platform the 



9 PDM may be directly connected to a Host Device, such as a PC or laptop, using a direct cable 

10 connected between the Host Device Com port and the PDM. The PDM will be configured as 

1 1 data communications equipment, or "DCE". The PDM acts as a "slave" operating with this 

12 platform, because it responds only to requests sent to it by the Host. In this manner, the Host 

13 sends a request and then the PDM answers the request with specific information within a set 

14 period of time. The PDM can respond to only one request at a time. An existing request must 

1 5 be either totally completed or a timeout declared before a successive request can be issued. 

16 An alternate or additional means of communication with the local Host is to use 

17 Infrared optical (IrDA) techniques. IrDA allows local communication between the PDM and a 

1 8 client device such as a desktop PC or laptop. IrDA may be used with or without cabling, thus 

19 removing the tether between the PDM and the local client. Another embodiment would 

20 provide RF communication between a local client such as a PC and the PDM, thus removing a 

2 1 line of sight requirement inherent with IrDA. 



22 When the PDM is in a server or slave capacity to a local Host, the PDM must always 

23 be available. This arrangement requires relatively high power consumption by the PDM. It is 

24 preferable that the PDM be powered by an external power adapter under these conditions. 

25 The local connection between client device and PDM (slave or server) platform has 

26 several uses. It is used in manufacturing for manufacturing tests and special servicing. It can 

27 be used in the field for downloading programs. It can be used in the field for refurbishment of 

28 the device, which includes cleaning of data memory, time setting, and controlling basic 

29 operating states. With this platform, a Host separate from the Host gathering user data can be 

30 used to provide servicing functions. 
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1 Because the PDM can communicate with these different platforms, several functions 

2 can be performed with the PDM. The PDM will support the following list of communication 

3 request types, at a minimum. Actual request transactions could include a concatenation of 

4 more than one these types. CDMA Host platform requests and RS232 platform requests are 

5 communicated over the same serial port. Only one of these platforms may operate at a given 

6 time. The PDM has logic to detect the type of cabling associated with the serial port, thus 

7 responding in an appropriate manner. Distinctions between CDMA Host Request and RS232 

8 platforms are included within the list as shown below: 

9 1 . Setting the Real Time Clock (RTC) with time and date, and retrieving RTC time and date 

1 0 from the PDM. A recommended format for RTC is Greenwich Mean Time (GMT). 

1 1 2. Retrieving and Setting of Patient identification data. Patient Identification data consists of 

12 128 bytes of free format ASCII data representing some description of the user/patient. 

13 3 . Retrieving and Setting of a Patient ID number. Such a number is an alias for the patient's 

14 actual name, and functions as a security measure. 

1 5 4. Retrieving and Setting of the PDM's operational profile(s). It is permissible to consider 

16 sending/receiving all profiles at once, or as separate profiles. Checksum operation should 

17 accompany the transmission of profiles. 

18 5 . Retrieving the PDM's internal status. 

1 9 6. Setting the PDM operational mode from a remote location. Among these, for example 

20 and without limitation, are power-ON/power-OFF, sleep/awake, idle, run, alarm, and the 

21 like. 

22 7. Retrieving the PDM manufacturing data, such as hardware serial number, software 

23 revision, unit type or class, build identification, and<other like data. Setting of this data is 

24 permissible with only the RS232 platform. 

25 8. Retrieving the PDM telecommunications data such as the assigned telephone number, IP 

26 address, etc. Setting of this data is permissible with only the RS232 platform. 

27 9. Retrieving and Setting of telephone call numbers. A Repository and Host Site telephone 

28 number, the Host Site URL address/password, and the Voice telephone number to use for 

29 emergency calling (such as with the panic button) are examples, without limitation, of 

30 important call numbers that users and caregivers would need readily available. 
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1 10. Retrieving of both the Most Oldest and the Most Current patient data records from logged 

2 memory by index numbers. 

3 11. Retrieving of a patient record specified by its index within logged memory. 

4 12. Retrieving of the most current data record as output by the PDM. Timed periodic data 

5 retrieval using this technique can allow continuous real-time waveform data transfer to a 

6 Host device. 

7 13. Erasing logged data. With separate special request, the entire logging memory may be 

8 erased. 

9 14. Performing the Reset of Alarms within the unit. 

10 15. Performing the Reset of Alerts within the unit. 

11 16. Retrieving and resetting voice call/data call instances and on-air accumulative time 

12 statistics. 

13 17. Using the RS232 platform only, the unit^firmware can be downloaded and programmed 

14 into the PDM by a Host device. Correspondingly, such firmware can be uploaded for 

15 verification. 

16 18. Using the RS232 platform only, the unit's voice synthesis sound set can be downloaded 

17 into the PDM by a Host device. Correspondingly, a sound set may be uploaded for 

18 verification. 

19 19. Using the RS232 platform only, diagnostic and special loading firmware may be 

20 downloaded and programmed into the PDM by a Host device. Correspondingly, such 

2 1 firmware may be uploaded for verification. 

22 20. Using the RS232 platform only, a special, protected request can be sent to the PDM from 

23 a Host device. The special request cleans all operational profiles to a default state, resets 

24 all alarms and alerts, erases all memory and patient data, and places the unit in IDLE 

25 mode. Such a request that causes multiple actions is useful for the healthcare provider to 

26 refurbish the unit for the next outgoing patient. 

27 21 . Instigating a specific audible sound phrase or tone of the voice synthesizer can be done 

28 from a Host device. Such requests can be used to alert the patient under unusual 
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1 conditions. Such requests also serve as diagnostic tools to ensure the PDM is working 

2 properly. 

3 22. Using the RS232 platform only, special diagnostic request may be issued from the Host 

4 device for test purposes. For example, a request may be sent to provide raw data from a 

5 measurement system. 

6 Data that is collected is encrypted to prevent eavesdropping or tampering with any 

7 commands. All information and data is Internet protocol compatible and contains error 

8 checking to insure data accuracy. 

9 The data acquisition module 42 continuously monitors, for example and without 



1 0 limitation, ECG and transmits that information from the PDM to the Internet. Transmission 

1 1 of data can be in real time and/or can be stored and forwarded depending upon the collection 

12 protocol ordered by the medical service provider. Similarly, temperature measurement, pulse 

13 oximetry, and pulse rate all can be collected and transmitted continuously during various 

14 periods of time or can be collected stored and burst transmitted over the wireless network as 

15 required. 

16 Measurement systems data is collected, reduced and stored to recording memory on a 

17 per second basis. If an operating profile calls for particular measurement duration of X 

18 seconds, then X successive logging records are produced during the X seconds. Note that the 

19 different measurement systems may be specified with interval times and duration that are not 

20 necessarily in synchronization with others. To resolve this difference in measurement data, 

21 data collection can be programmed in sums of the aggregate of all interval times and duration 

22 together to derive an aggregate interval time and duration. The Host that generates the 

23 operating profiles must come up with efficient schemes for specifying the measurement 

24 intervals and duration collectively. 



25 The timekeeping mechanism for determining when a measurement recording is to 

26 take place is the Real-Time Clock (RTC) that provides time 48. Each stored record of 

27 measurements contains a time stamp and the current internal status of the PDM. 

28 When the PDM enters the Alarm Mode (discussed in more detail below), all 



29 measurement data is recorded continually with once a second records until relieved by a 

30 communication request. Recording Data Memory 594 (see figure 5) is constrained by 

31 storage capacity in a small and portable device. Therefore, it will typically be arranged as a 

32 wrap-around memory. It is cautionary to note that when memory becomes full, the 

33 recording process continues with the oldest data becoming overwritten. 

14 



WO 02/067122 



PCT/US02/04369 



1 Pointers and indexers manage Recording Data Memory 594. As such, the Recording 

2 Data Memory 594 along with its pointers and indexers are non-volatile. Indexers allow a 

3 Host System to request and retrieve any particular logging record via communication 

4 interface. Patient recording memory is allocated in buffers of size a multiple 16, up to a IK 

5 buffer (1024 bytes). Another embodiment would store records of one size in one area of 

6 memory and buffers of another size in a unique section of memory. If the measurement 

7 system only contained discrete data (i.e., integers) then the buffer size could be uniformly 16 

8 bytes. If, however, the data was a mix of discrete and analog information (e.g., waveforms) 

9 the records might have to have buffers of mixed sizes. For example, 16-byte records might be 
10 used for pulse rate and 128-byte records for ECG information. 



1 1 Records are chronologically sequenced within regions, the lowest numbered records 

12 being the oldest. The 16-byte records would contain a time stamp plus the discrete data plus 

13 the PDM's internal status at the particular time stamp. Whereas a waveform record would 

14 only have a timestamp and the waveform analog representation in that record. Records would 

15 not have negative timestamps. A waveform record will always have a corresponding discrete 

16 record associated with the waveform record. The corollary, a discrete record will always have 

17 a waveform record associated with it, may not be true. 

18 There is a finite amount of patient recording memory and thus the records wrap in 

19 memory. That is, the eldest records are overwritten with current records when the record 

20 memory area is full. The wrap points are maintained, thus creating a virtual chronologically 

2 1 sequenced record memory. 

22 The data acquisition module 42 contains logic that allows an "alarm" condition to be 



23 transmitted at any time whenever the alarm criteria are fulfilled. Further, any alarm condition 

24 must be reset by the health care provider by directing the Host clear the alarm through the 

25 Internet and then over the wireless network. Any "sensor off signals 62, occurring for 

26 example when a sensor is turned off, broken, or has become disconnected, is sent upon 

27 occurrence. The patient is alerted to take appropriate action, such as replacing or repairing 

28 the sensor. While such information is transmitted by the data acquisition module 42 to the 

29 CDMA module 56 (or cellular telephone 11) and thence to the wireless network, a voice 

30 synthesizer or other sound generator also provides an audible alert to speaker 60 to the patient 

3 1 that a particular alarm or sensor off condition has occurred. 

32 As noted earlier, the patient using the PDM also has the capability to automatically 

33 (or speed dial) 91 1 as needed. Data acquisition module 42 also processes this information 
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1 and passes it over a voice connection 50 to CDMA module 56 and thereafter to the wireless 

2 network for communication. 

3 The patient also has the ability to call 40 the medical care provider (i.e., 28) on a non- 

4 emergency basis. This is accomplished by a dedicated function speed dial "button" on the 

5 PDM. Again, data acquisition module 42 processes voice information 50 and passes that 

6 information to the CDMA module 56. The PDM has voice call capability with use of the 

7 CDMA phone. The user can instigate such calls with buttons on the PDM front panel. The 

8 PDM further has an auto-dial capability. The PDM stores and accesses a table of voice call 

9 phone numbers to make automatic dialing calls when the front panel buttons are depressed. 

10 Likewise, the front panel buttons are also used to terminate (hang-up) a voice call. Two types 

1 1 of automatic call dialing can be performed. A call can be made to a specifically stored voice 

12 number, such as a health care provider via 40. A call 38 can also be made to emergency 

13 services, such as a 91 1 call. 

14 The data acquisition module 42 assigns priority to voice calls over CDMA data calls. 

1 5 When a voice call is instigated by the patient, any data calls in process will be terminated. A 

16 voice call instigated by the Host when data is being posted will fail until the PDM post is 

17 finished. The health care provider may instigate a voice call. The PDM has logic to distinguish 

1 8 between a CDMA Host request and a voice call. 

19 As previously discussed, the data acquisition module contains logic that allows an 

20 "alarm" condition be transmitted at any time whenever alarm conditions are met. In the PDM, 

21 alarms and alerts cause the system to change modes and to inform the patient of the condition 

22 that caused the change. Alarms relate to one or more physiological measurements falling 

23 outside of set limits. As an additional safety feature the exceeded limits must persist for a 

24 specified minimum duration before the condition can be declared a tripped alarm (reducing 

25 false alarms). 

26 Alarms are used to notify the patient and/or health care provider of patient conditions 

27 that require caregiver attention. Alarms are activated when a physiological measurement 

28 exceeds high or low limits for a prescribed time (persistence) period. Both the limits and the 

29 persistence period for each parameter are set by the caregiver and stored in the profile. The 

30 alarm for each parameter may be disabled by the caregiver with settings in the profile (See 

3 1 detailed profile description below). Once an alarm is activated, it can only be cleared by the 

32 Host. The measured parameter causing the alarm is recorded in PDM memory until the alarm 
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1 mode is transitioned to idle mode (See Figure 3 description). The PDM contacts the Host, 

2 which in turn contacts the caregiver with information. The voice message system is activated 

3 to inform the patient that an alarm condition has occurred. 

4 Alerts relate to sensor errors or device hardware warning/malfunction. Alerts are used 

5 to inform the patient that the system is not operating properly and that corrective action is 

6 required If an alert is in force for a measured parameter, then any alarms associated with the 

7 parameter are not allowed to activate. There are two classes of alerts;(l) recoverable and (2) 

8 system failures 

9 Recoverable Alerts - These are alerts that may be corrected by the patient. Such an 

1 0 alert may be caused by a detached or disconnected sensor. The alert is cleared when the 

1 1 patient corrects the problem. Another example of a recoverable alert occurs when a PDM is 

12 out of RF signal range. Again, if the patient is informed about this, the signal range condition 

13 might be correctable. Still another example is 'battery low' which requires the patient to 

14 replace the batteries. A last example occurs when the recording memory becomes close to 

15 full. However, in such cases, it is the Host's responsibility to detect this alert and perform 

16 automatic measures to relieve it. 



1 7 System Failures (or Non-Recoverable Alerts) are errors that can be associated with 

1 8 system problems, such as memory error or RTC error. Such alerts require technical 

19 intervention. The patient is must contact the caregiver via a voice call to get a replacement 

20 PDM. 

21 As noted above, the medical service provider or other organization that is responsible 



22 for monitoring and maintaining of the PDM can interrogate 52 the data acquisition module 42 

23 of the PDM. A request for information flows from the medical care provider over the 

24 Internet to the Host. The Host initiates a voice call to the PDM, which triggers the PDM to 

25 establish a data call back to the Host. Alternatively, the data acquisition module can be 

26 reconfigured 54 to update communications capabilities, or to change the protocol for 

27 frequency of monitoring physiologic data and alarm limits. 

28 The PDM can be programmed to operate according to several different operating 

29 profiles. When operating, the PDM is governed by the Operating Profile in force at the time. 

30 One embodiment provides for three profiles. A fourth, profile, generated internally by the 

3 1 PDM, is the alarm profile which supercedes any other current profiles when an alarm 

32 condition occurs. 
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1 The PDM operates on a 24-hour-period basis. An operating profile therefore contains 

2 a start and stop time within the 24-hour cycle that determines when it is in force. The start 

3 and stop time is expressed in minutes after midnight. The maximum in-force time can be 24 

4 hours when there is 24 hour's difference between start and stop time. The 24-hour profile 

5 might contain a start time of 0 and a stop time of 1440.The minimum in-force time can be 0 

6 hours if start and stop times are the same. This configuration causes a profile to be inactive. 

7 While Start and Stop times are specified in minutes passed midnight as based on the RTC, 

8 any unambiguous start and stop time setting method will be sufficient. Profiles are set from a 

9 Host device. 



10 Profiles can be engaged to cover a specific portion of the day if desired. For instance: 

1 1 Profile 1 could be assigned from midnight to 6 AM, Profile 2 could be assigned from 6AM to 

12 8 PM, and Profile 3 could be assigned from 8PM to midnight. The Start and Stop time can 

13 span across midnight (for example start =10 PM, stop = 2 AM). 

14 Profiles can have start and stop time overlaps during the 24-hour period, thus 

15 permitting another dimension of flexibility. In such case, Profile 1 has greatest priority 

16 during an overlap, and Profile 3 has least priority. Profiles can be set for a portion of the day 

17 to have an absent profile assignment. When an absent profile is in force, and the unit does no 

1 8 measurement or recording. 

19 Each profile contains a control block made up of multiple parameters. The following 



20 parameters and rules set comprise one embodiment of parameters, but is not meant to be a 

21 limitation. A Start and Stop Time is set in minutes. A Periodic Posting Period is set in 

22 minutes. The Periodic Posting Period is the periodic interval in which the PDM will attempt 

23 to post data to the Host Site. An Enable/Disable switch is set for each measurement system. 

24 Disable means that the particular measurement system will be put to sleep entirely while the 

25 profile is in force. A Measurement Interval Time (in seconds) is provided for each 

26 measurement system run by the PDM. This interval time determines the length of time 

27 between a measurement recording session. A Measurement Duration Time (in seconds) is set 

28 for each measurement system. For example, the ECG measurement may be data logged 

29 every 20 minutes for a measurement duration of 30 seconds. For this example, the 

30 measurement duration is set to 30 and the interval is set to 1200 seconds. 

3 1 Several control block settings address alarms. Each measurement system has an 

32 alarm enable/disable switch. Each alarm will have a high and low limit value. However, 

33 exceptions to the limits can be set. Limits for each patient will be different, and must be 
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1 interpreted by a caregiver. Each alarm will have an alarm persistence time set. Persistence 

2 time is the amount of time in seconds that an alarm condition must be breached continuously 

3 before it is declared tripped. 

4 Another control setting is an Event Mode duration time. An 'Event' is 

5 discussed later in detail. When the patient pushing the Event button instigates an Event, the 

6 unit enters Event Mode for the duration time, then returns back to its previous Mode. Each 

7 profile contains check bytes. The check bytes must be verified on a periodic basis. It must 

8 also be verified when the profile is modified. 

9 The profiles of the PDM are considered vital to operation and are stored in non- 
10 volatile memory. If the profiles are to be changed, the following is one embodiment for 

1 1 executing changes to the profiles. First, the profiles are retrieved from the PDM by making a 

12 Host request. Next, a check of validity is made using the check characters. Next the one or 

13 more profiles are edited for any parameter changes. New check character must also be 

14 provided in the profiles. A request is then made of the PDM to load the profiles. Check 

15 characters should also be loaded. The PDM loads the revised profiles and check character 

16 data into non-volatile memory. Flash memory usually serves as non-volatile memory. After 

17 flash memory has been modified, the Host requests profile status. The PDM response is 

1 8 checked for correct implementation of the profile changes. 

19 In Figure 3, the PDM operational mode state transition model is illustrated. 

20 The PDM operates according to four operational modes. They are: Idle Mode 200 

21 Active Mode 210, Alarm Mode 230, and Event Mode 220. In Idle Mode 200, the profiles are 

22 disarmed and all alerts are disarmed. Transition to Idle Mode 200 can be initiated by the Host 

23 or the local PC or laptop via a RS232 connection. A patient-initiated transition 212 to Idle 

24 mode from Active mode is implemented when the patient depresses a pause key located on the 

25 face of the PDM unit. Pause key implementation is regulated by the profile in effect. Further, 

26 the transition to Idle Mode is of a fixed duration as set in the current profile. While the PDM is 

27 in Idle mode 200 the current profile is disabled and there is no data acquisition and no 

28 receding. Further, even if in Idle mode because of a patient initiated pause, alarm and alert 

29 detection are disabled. A record is stored to recording memory at the start of the Pause, hence 

30 the status in the record will mark the pause. Return from Idle Mode 200 to Active mode 210 

3 1 occurs at pause expiration 204. 
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1 Transition from an Alarm Mode to Idle Mode is via a Host request 232. This transition 

2 clears the alarm condition. Transition from Active Mode to Idle Mode, not pause key driven, 

3 is achieved via RS232/Host request 214 The PDM will respond to RS232/Host request to go 

4 active 202. Idle Mode is used when it is desired to modify operational profiles, set time, 

5 change the patient identification, etc. Once in Idle Mode, the PDM can only go to Active 

6 Mode by RS232/Host request 202 or by Pause Expiration 204. 



7 Active Mode 210 is used whenever the PDM unit is fully performing the profile in 

8 force. Alarms as governed by the profile in force may be armed. All alerts are armed. The 

9 PDM can further change from Active Mode to Event mode 220 when Event Button initiated 

10 transition 218 occurs or to Alarm Mode when an Alarm trip 216 occurs 

1 1 Alarm Mode 230 operates once the unit has had an alarm trip 216 and transition occurs 



12 from Event mode or Active mode. During an alarm, data is continually being measured and 

13 logged. Logged data is identified as Alarm Mode data. Successive attempts are made to 

14 connect with the Host Site to post data. The Host Site should always check the internal status 

15 of the PDM for alarms. Voice messages or audible signals are generated during Alarm Mode. 

16 The current operational profile is "locked". That is, the unit will remain at the profile in 

1 7 which the trip occurred until the unit is forced into Idle Mode 200 by Host request 232. The 

1 8 alarm bits of the internal status are reset when the PDM is transitioned to Idle mode. This 

1 9 clears any alarms . 

20 Event Mode 220 begins when the patient pushes the front panel Event button 218. 

21 Event Mode 220 preempts the Active Mode 210, but has a definite duration time when there is 

22 a transition back 222 to Active Mode 210. During Event Mode 220, data is continually being 

23 measured and logged. Logged data is identified as Event Mode data. If the patient depresses 

24 the Event Mode button and the unit is already in Event Mode then this will reinitialize the 

25 duration timer. Thus Event Mode duration is extended. From the Event Mode, the PDM can 

26 either return to Active Mode at expiration of Duration time 222 or go to Alarm mode if there 

27 is an alarm trip 216 or to Idle Mode by Host request 224. 

28 The PDM further monitors its own internal status. The PDM records: (1) the status of 

29 measurement systems (active, disabled, etc.); (2) alarm status for each measurement system; 

30 (3) alert status; (4) current operation mode; (5) current profile in force; (6) communication 

3 1 signal status; and (7) recording memory status. Status will be preserved during power-down 
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1 periods and restored on subsequent Power-On. This preservation requirement extends to 

2 abnormal power-down situations as well, such as an accidental power disconnection. 

3 The PDM runs a power management system. The PDM detects low power, conserves 

4 power, runs safety checks, and alarms when power is interrupted. The PDM periodically 

5 monitors its battery voltage and indicates the current battery capacity at the front panel display 

6 with an indicator. At least two thresholds are checked. If the battery voltage falls below the 

7 first of these, then a low battery alert is active. If it falls below the second, then automatic 

8 power shutdown occurs. The unit must be able to anticipate if it has enough battery capacity 

9 to drive communications each time such communication is established. 

10 The PDM runs a power conservation algorithm. The PDM has a modularized 

1 1 system and sub-system architecture such that those systems that are momentary or long-term 

12 idle 

13 can be either shut down or low-power throttled. If the voice synthesizer is not sending 

14 messages, then the voice synthesizer sub-system is shut down. If a particular measurement is 

15 not 

16 active, then that measurement subsystem is powered down. 
17 



18 Power conservation extends to the core processing system itself. Clocks and 

19 peripherals within this core are powered down or throttled down, if it can be done safely. 

20 Safety measures include a "watchdog" system (see 599 in figure 5), a periodic 

21 crosscheck that assures that both the system clock and the RTC are operating normally. The 

22 PDM additionally runs a power-ON confidence test. The PDM contains a diagnostic 

23 program which can be invoked either with a special sequence of interaction with the front 

24 panel, or with requests via RS232 communication request port. 

25 A Power Interruption Alarm is run by the PDM. The PDM contains an independent 



26 battery-powered alarm subsystem that monitors main power-on. If the main battery power to 

27 the PDM is interrupted while in the power-on condition, or if the PDM watchdog is tripped, 

28 then this subsystem will cause an audible alarm and set a condition in the internal status. 

29 The subsystem will remain in a tripped condition until the patient resets the alarm via front 

30 panel menu interaction, or the alarm is reset via a communication request. 

3 1 The system of the present invention includes the network and can allow simultaneous 

32 operation of any number of PDMs. This system is only limited by the capacity of the 

33 wireless network to handle traffic. In the same fashion that a cellular telephone has a 
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1 roaming capability, so does the PDM, therefore allowing continual transmission and updating 

2 of physiologic data. 

3 In Figure 4, a front panel for the PDM is illustrated. The PDM has a time of day 72 

4 and a battery capacity and signal strength indicators 74 which allow the patient wearing the 

5 device to determine if recharging or battery replacement is required. The patient can further 

6 determine whether the signal strength of the communications channel is adequate to support 

7 reliable communications. The panel 70 is dimensioned to be small and unobtrusive so that 

8 the wearer will not be disproportionately burdened by carrying the PDM. The panel has 

9 several speed dialing preset buttons that allow emergency calls to 91 1 76 to be made and 

10 calls to the care provider 78 to be made simply by the press of a button. Similarly, if the 

1 1 wearer determines that an "event" has occurred such as faintness, shortness of breath, 

12 irregular heartbeat, or other symptoms, this event button 80 can be pressed and a signal 

13 generated associated with the event. A power indicator 82 is part of the panel so that the user 

14 can determine that power is "on." Sensor lamp 86 is on the panel as well to inform the user 

1 5 whether all sensors are operating or if a sensor has potentially become disconnected or has 

16 otherwise malfunctioned. An alarm display 84 together with an audible signal is also present 

17 on the control panel so that the patient can have both a visual and audible warning of any 

1 8 alarm condition that might exist. 

19 A Pause button 81 allows the patient to disengage from the PDM for a brief time 

20 period. For example, if the patient wants to shower, the wearer depresses the pause button 

21 and the operational mode will transition to Idle. The pause button invocation is ignored if an 

22 Alarm or Event is in progress. Further, the current profile in effect must allow for the 

23 implementation of a pause. 

24 The profile in effect also provides for a pause duration. Once the pause duration is 

25 exhausted, the PDM reverts to active mode. An alternative embodiment would allow the 

26 PDM wearer to terminate the pause (Idle) mode prior to the allotted pause time allotment. For 

27 example, the patient, having finished showering and having re-established the sensor 

28 placements, would signal the PDM to become active by depressing the pause button for three 

29 seconds, thus causing a transition to the active mode before the pause timeout expired. 

30 Control buttons for volume 88 and mute 90 are located on the face of the PDM. A 

3 1 Menu Button 92 present a list of menu options to the display, along with a cursor. The 

32 patient may move the cursor with the Up/Down Select button 94. He may then execute a 

33 menu item with a push of the Execute button 96. The Escape button 98 serves a way to back 
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1 out of a previous menu selection. Obviously, such menu selections could also be used 

2 through a "touchscreen" interface. 
3 

4 The panel further contains a bit-mapped array LCD display 100. The display 100 

5 provides a status of the following features: (2) time and date (military or AM/PM format); 

6 (2) Current Status of the unit (operational mode, listing of pending alerts and alarms); (3) 

7 Voice Call Status; (4) Error Correction Guidance Messages (when appropriate); and a (3) 

8 Menu Tool Bar. From the Menu Tool Bar display, the user may configure settings to view: 

9 (1) Time format (Military or AM/PM); (2) Sound Volume Up/Down; (3)Current 

10 measurement value; (4)Total recording memory capacity and remaining availability; (5) 

1 1 Voice telephone number table entry; (6) Current signal strength; (7) Profile in force with 

12 start and stop times; and (8) Battery Capacity. The panel also serves as a touchscreen that 

1 3 enables the user to select a function simply by pressing a portion of the display with his 

14 fingertip. 

15 The panel design shown in this Figure 4 is by way of illustration only. It will be 

16 apparent to those skilled in the art that other panel designs, including a touchscreen display, 

17 are possible so long as the information is presented and transferred in an easy and useable 

18 way for the patient. 

19 As noted above, the communications link between the PDM and the care provider via 

20 the PSTN or the Internet is a bi-directional link. Thus requests for data from a workstation 

21 located at the care provider's facility can be transmitted through the Internet to the Host 

22 which in turn contacts the PDM. Data (real-time or stored) can be transferred from the PDM 

23 through the Internet to various databases for analysis or storage. Data from the PDM can be 

24 transferred in real-time or from storage through the Internet to other authorized users such as 

25 insurance providers. Alarm information is transferred from the PDM to the care provider 

26 through the Internet. When a sensor malfunctions or becomes disconnected from the wearer, 

27 a "sensor off 5 signal is sent from the PDM and transferred over the Internet to the medical 

28 care provider so that such information is available and so that the patient can be assisted in 

29 troubleshooting the cause of the alert. Event information, as described earlier, can be 

30 transferred to the medical care provider through the Host. The medical care provider can 

3 1 transmit a communication to disarm or reset alarms in the PDM through the Internet as 

32 necessary. Further, protocols relating to the schedule and type of bio-signal to be measured 

33 can be sent from the medical provider through the Internet to the PDM. The personal 
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1 emergency button for use to activate a call from the patient to the medical care provider or 

2 911 emergency operator provides voice communication from the PDM to and from the care 

3 provider. Real-time clock resets or any other variations in configuration of the PDM can be 

4 transmitted from the medical care provider over the Internet to the PDM. 

5 In Figure 5, the architecture of the PDM 12A is illustrated. Several systems and 

6 components are housed within the PDM 12A. The PDM 12A contains a processor 590, 

7 memory 592, recording data memory 594, a power system 595, manual reset logic 596, a 

8 watch dog system 599, the CDMA module 56 (previously described in Figure 2), the data 

9 acquisition module 42 (previously described in Figure 2), input/output means such as Serial 

10 port 112, IrDA port 114, microphone/speaker 60, display screen 100 and keypad 110. These 

1 1 systems are electronically connected to and operate the PDM 12. 

12 The processor 590 of the PDM 12 executes operating profiles, setting the PDM to 

13 various operational modes, checking internal status, setting alarm or alert conditions, 

14 recording data, and sending and receiving audio and text messages. A thirty-two bit 

15 microprocessor is used in the PDM. One example of a suitable microprocessor model is the 

1 6 ARM7DTMI made by ARM, Limited. The memory 592 of the PDM is used to store 

17 operating instructions executed by the processor 590. Memory 592 further stores patient 

18 data, current status, current mode, messaging data, numbers for automatic dialing. One 

19 embodiment provides for a memory chip having 32 megabytes of storage used with the 

20 present invention, although is not meant as a limitation. 



21 The PDM 12 further houses a power management system, which manages battery 

22 power and metering in a manner known to those skilled in the art. 

23 In a preferred embodiment, the PDM uses an LCD touch screen display 600 as 

24 illustrated in figure 6. The following information is displayed on the LCD whenever it is on: 

25 TABLE 1 

26 SENSORS 602 STATUS 606 

27 OK RUN 

28 OFF EVENT 

29 PAUSE 
30 

3 1 ALARMS 604 SIGNAL 608 

32 ON OK 

33 OFF WEAK 

24 
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1 NONE 
2 

3 BATTERY 610 DATE 612 TIME 614 

4 100% XX-XX-XX XX:XXAM 

5 75% XX:XXPM 

6 50% 

7 25% 

8 LOW 
9 

10 Two active touchscreen areas on the PDM display are allocated to YES 620 and NO 



1 1 622 answers. Additional touchscreen areas 624, 626 are allocated for use by the patient to 

12 control the volume of the beeps and audio messages. Expansion of these areas into numerical 

13 regions is also possible. Additional areas 628 and 630 are used for internally instigated PDM 

14 massages and messages requiring the users attention. 

15 An earset tone and a room-audible beep are generated for every message, whether 

16 written or spoken. As illustrated in Table 1, a distinctive beep is generated for each class of 

17 message. Questions are stored in a messaging profile to be triggered at the pre-set time. Up to 

18 20 questions can be hard-coded into the system. A "Care Manager" picks from pre-selected 

19 messages to be sent at a pre-selected time of day. It is also desirable to include a capability 

20 for caregivers to ask a custom question over the Internet. Answers to questions are 

21 transmitted only when the system does a "post' operation per profile or upon a command 

22 from the Care Manager. The system will "post" data whenever patient triggers the "Pause" 

23 button, the activation of which will idle the system for 30 minutes after each press. 



24 Voice messaging and phone voice occur simultaneously (additive) in the earset. 

25 Pressing any of the buttons on the front panel (including the touchscreen) will cause a short 

26 beep tone (Beep # 1 , external) to be emitted. 

27 Patients using the PDM are instructed to respond to all messages as they are received. 

28 The acknowledgement of an instruction (not a question) is by an input of YES 620 by the 

29 patient using the touchscreen. 

30 In a preferred embodiment, the bi-directional communication between the sensors and 

3 1 voice data acquisition devices of the PDM and host server on the Internet are accomplished 

32 without use of a modem by use of a Sensor and Instrument Interface Communication Module 

33 (SIICM), disclosed in co-pending U.S. Provisional Application Serial No. 60/292,065, filed 

25 
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1 May 1 8 3 2001 . The SIICM provides the data acquisition circuitry required to gather various 

2 signals from sensors for a variety data (including physiologic data from the human body or 

3 data from remote non-medical monitoring instrumentation) and to condition those signals for 

4 interface to a variety of possible digital cellular phone or other wireless communication 

5 modules which are used to transmit these data into the digital cellular network for distribution 

6 on the Internet. 

7 Figure 7 is a sketch of the essential features of a Wireless Data Communicator, 

8 comprised of a Sensor Instrument Interface Module 710 (SUM) connected to a 

9 Receiver/Transmitter Module 720 (RTM) which provides the wireless interface to the 

10 Internet. The sensors, as noted above, can be any of a wide variety of physical and 

1 1 biosensors generally used to detect signals or variables from the (1) human body, (2) 

12 instruments, (3) equipment, (4) environment, etc. Sensors and instruments used in measuring 

13 clinically relevant data are of particular interest for use in this system. Such data include 

14 electrocardiogram, temperature, respiration, acceleration, audio, oximetry, blood glucose, 

15 body weight, capnogram, geographic position (GPS), blood pressure, keyboard, pipeline 

16 pressure, etc. The RTM can contain a variety of wireless communication protocols; e.g., 

17 CDMA, TDMA, GSM, IEEE802.il, etc. 



18 Power 730 can be supplied from a variety of sources that include batteries, solar cells, 

19 fuel cells, AC lines, etc. Specialized sensor interface modules can be plugged into ports 740- 

20 746 of the SIICM to interface with a wider variety of sensors, instruments, or equipment. 

21 The SIICM is designed to recognize the characteristics of the sensor, instrument, or 



22 equipment to which it is attached and to encode the transmitted data in a manner that will 

23 allow a central Internet database to interpret and display the data. Since the wireless data 

24 communicator has two-way digital communications capability, a smart sensor interface 

25 (similar to "plug and play") can be implemented either in the memory of the SUM or the 

26 SIICM can be configured remotely by commands from the central Internet database to 

27 recognize the interface. 



28 The preferred communication form of the present invention is disclosed in co-pending 

29 U.S. Provisional Application Serial No. 60/292,068, filed May 1 8, 200 1 . In this preferred 

30 system, a high-level Extensible Markup Language (XML) structure and communication 

31 process is used, as disclosed below. 

32 In this embodiment, the patient data monitoring is implemented for wireless 

33 communications between the Host (PhDx) and the remote PDM (PDM2000) by using an 

26 
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1 XML message schema, an XML transaction schema for scheduled sensor data, and an XML 

2 transaction schema for acknowledgement (ACK) data. 

3 XML Message Schema 

4 The XML schema used to validate the high-level XML message structure is shown 

5 below: 

6 <?xml version="l .0"?> 

7 < Schema • 

8 name= " PhDxPDM2 0 0 OMSGSchema " 

9 xmlns= f, urn : schemas-microsof t-com : xml-data " 

1 0 xmlns : dt="urn : schemas-microsof t-com : datatypes "> 
11 

12 <ElementType name^'MSG 1 content= ' eltOnly 1 > 

13 <element type= f MID' minOccurs= 1 1 ' maxOccurs= 1 1 ? /> 

14 <element type= , MDT l minOccurs= , l l maxOccurs= 1 1 1 /> 

15 <element type='MTY' minOccurs='l' maxOccurs=' 1 ' /> 

16 <element type^CMM 1 minOccurs^ 1 1 ' maxOccurs= f 1 1 /> 

17 <element type= , CID l minOccurs= l 1 1 maxOccurs^ 1 1 ' /> 

18 <element type^'EID 1 minOccurs= ' 1 1 maxOccurs= ! 1 1 /> 

19 <element type='RID' minOccurs= ' 1 ' maxOccurs=' 1 ' /> 

20 <element type- f TCT* minOccurs= • 1 » maxOccurs= 1 1 ? /> 

21 <element type^'TRA 1 minOccurs= 1 1 1 maxOccurs^ 1 * ' /> 

22 </ElementType> 
23 

24 <ElementType name^'MID' content= ■ textOnly' dt : type^ 1 int 1 /> 

25 <ElementType nan^'MOT' content='textOnly' dt : type='dateTime ' /> 

26 <Ele i mentType name^'MTY 1 content= f textOnly 1 dt : type= f int 1 /> 

27 <ElementType name=* 1 CMM 1 content= f textOnly* dt : type=*' int ' /> 

28 <ElementType name^'CID 1 content^ 1 textOnly 1 dt : type= 1 int 1 /> 

29 <ElementType name= f EID' content^' textOnly 1 dt : type='int '/> 

30 <ElementType nan^'RID' content^'textOnly 1 dt : type= 1 int 1 /> 

31 <ElementType name^'TCT' content-' textOnly 1 dt : type= 1 int 1 /> 

32 <ElementType name= ' TRA' content='eltOnly'> 

33 <element type= f TID f minOccurs= t 1 1 maxOccurs=' 1 1 /> 

34 <element type= T TCD 1 minOccurs= 1 1 1 maxOccurs= 1 1 1 /> 

35 <element type= 1 TVL 1 minOccurs= 1 1 r maxOccurs= 1 1 ' /> 

36 </ElementType> 
37 

38 <ElementType name= , TID t content^ textOnly 1 dt: type='int '/> 

39 <ElementType name^TCD 1 content=' textOnly r dt:type=*int'/> 

27 
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1 <ElementType name= ' TVL ' content 3 1 eltOnly ' /> 

2 </Schema> 
3 

4 XML Transaction Schema - Scheduled Sensor Data 

5 The XML schema used to validate the lower-level XML transaction structure for a 



6 scheduled sensor data post is shown below, A separate schema exists for each of the 

7 different transaction types. 
8 

9 <?xml version 3 "1.0"?> 

10 <Schema 



1 1 name 3 "PDM2000Schema_POSTSCHEDULEDSENSORDATA" 

12 xmlns 3 "urn: schemas-microsof t -com: xml -data" 

13 xmlns :dt 3 "urn: schemas-microsof t-com: datatypes "> 
14 

15 <ElementType name 3 'TVL' content 3 f eltOnly'> 

16 <element type='TVO' minOccurs= ' 1 1 maxOccurs 3 ' 1 ' /> 

17 <element type= , TVT t minOccurs 3 ' 1 ' maxOccurs 3 ' 1 ' /> 

18 <element type='TVH' minOccurs= 1 1 f maxOccurs 3 ' 1 ' /> 

19 <element type='DSS' minOccurs= f 1 1 maxOccurs 3 ' 1 1 /> 

20 <element type 3 'DES' minOccurs 3 ' 1 ' maxOccurs 3 ' 1 • /> 

21 </ElementType> 
22 

23 <ElementType name 3 'TVO' content 31 textOnly ' dt : type 3 ' int ' /> 

24 <ElementType name='TVT ! content 3 ' textOnly 1 dt: type 3 'float ' /> 

25 <ElementType name^TVH 1 content 3 ' textOnly ' dt : type 3 ' int ' /> 

26 <ElementType name 3 'DSS' content 3 1 textOnly 1 dt : type 3 ' bin. hex* /> 

27 <ElementType name 3, DES' content 3 ' eltOnly ' > 

28 <element type='CCC f minOccurs 3 ' 1 ' maxOccurs 31 1 1 /> 

29 <element type 3 'CBC minOccurs 3 ' 1 ' maxOccurs 3 ' 1 1 /> 

30 <element type 3 'TSI' minOccurs 3 ' 1 ' maxOccurs 3 ' 1 ' /> 

31 <element type 3 'OSI' minOccurs 3 ' 1 1 maxOccurs 3 ' 1 ' /> 

32 <element type 3 'PAC minOccurs 3 ' 1 1 maxOccurs 3 ' l f /> 

33 <element type='CER' minOccurs 3 ' 1 1 maxOccurs 3 1 1 1 /> 

34 <element type 3l PRF r minOccurs 3 ' 1 1 maxOccurs 3 ' l'/> 

35 <element type 3 'MOD 1 minOccurs 3 1 1 1 maxOccurs 3 ' 1 ' /> 

36 <element type 3 'PAU' minOccurs 3 ' 1 1 maxOccurs 3 ' 1 ' /> 

37 </ElementType> 
38 
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1 <ElementType name^'CCC content^ 1 textOnly' 

2 dt:type='intV> 

3 <ElementType name^'CBC 1 content= ! textOnly f 

4 dt:type= , int , /> 

5 <ElementType narae='TSI' content='textOniy 1 

6 dt:type= , int ' /> 

7 <ElementType name= , OSI I content^' textOnly ' 

8 dt:type= , int , /> 

9 <ElementType name^'PAC content= 1 textOnly ' 

10 dt:type= , int , /> 

11 <ElementType name= f CER f content^ textOnly' 

12 dt:type='intV> 

13 <ElementType name='PRF' content= f textOnly 1 

14 dt:type='int •/> 

15 <ElementType name= f M0D ! content^ 1 textOnly ' 

16 dt : type=» int f /> 

17 <ElementType name= f PAU f content^' textOnly' 



18 dt:type='int T /> 
19 

20 </Schema> 
21 

22 Example - Scheduled Sensor Data Post 



23 The scheduled sensor data transaction posts the personal sensor measurements (taken 

24 as scheduled by the PDM's internal sensor profile settings) from the PDM to the server. As 

25 shown in the table below, this transaction contains the sensor values, the device standard 

26 status, and the device extended status. 

27 The full set of message tags is as follows: 

28 <MSG> 

29 <MID>MESSAGEJED</MID> 

30 <MDT>MESSAGE_DATE</MDT> 

31 <MTY>DATAPOSTSET</MTY> 

32 <CMM>COMM_MODE</CMM> 

33 <CID>CLIENT_ID</CID> 

34 <E I D>EXTERNAL_ID< /EI D> 

35 <RID>0</RID> 

36 <TCT>1</TCT> 

37 <TRA> 

38 <TID>TRANSACTION ID</TID> 
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1 <TCD>SCHEDULED__SENSOR_DATAPOST</TCD> 

2 <TVL> 

3 <TVO>100</TVO> 

4 <TVT>98.6</TVT> 

5 <TVH>75</TVH> 

6 < DS S> P DM_S T ANDARD_S TATUS_1 6 J3 YTE_RE CORD< / DS S > 

7 <DES> 

8 <CCC>0</CCC> 

9 <CBC>0</CBC> 

10 <TSI>0</TSI> 

11 <OSI>0</OSI> 

12 <PAC>0</PAC> 

13 <CER>0</CER> 

14 <PRF>0</PRF> 

15 <MOD>0</MOD> 

16 <PAU>0</PAU> 

17 </DES> 

18 </TVL> 

19 </TRA> 

20 </MSG> 
21 

22 XML Transaction Schema - Acknowledgement (ACK) 

23 The XML schema used to validate the lower-level XML transaction structure for a 

24 message acknowledgement (ACK) is shown below. A separate schema exists for each of the 

25 different transaction types. 

26 <?xml version="1.0"?> 

27 <?xml version="1.0"?> 
28 

29 < Schema 

30 name= ,, PDM2000Schema_ACK" 

3 1 xmlns="urn : schemas -microsoft-corn : xml-data" 

32 xmlns :dt="urn: schemas -micro soft-com: datatypes'^ 
33 

34 <ElementType name^'TVL 1 content= ! eltOnly ■> 

35 <element type= 1 VAL 1 minOccurs= 1 1 1 maxOccur s= ? 1 * /> 

36 </ElementType> 

37 <ElementType name-'VAL 1 content= f textOnly • dt : type=' string 1 /> 
38 

39 </Schema> 
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1 Example - The Acknowledge (ACK) Message 

2 The Acknowledge (ACK) message is defined as follows: 

3 <MSG> 

4 <MID>MESSAGE_ID</MID> 

5 <MDT >ME S S AGE_DAT E < / MDT > 

6 <MTY>ACK</MTY> 

7 <CMM>COMM_MODE</CMM> 

8 <CID>CLIENT_ID</CID> 

9 <EID>EXTERNAL_ID</EID> 

10 <RID>REFERENCE_MESSAGE_ID</RID> 

11 <TCT>1</TCT> 
12 

13 <TID>TRANSACTION_ID</TID> 

14 <TCD>ACKTRAN</TCD> 

15 <TVL> 

16 <VAL>VALUE</VAL> 

17 </TVL> 

18 <TRA> 

19 </MSG> 

20 

2 1 Message Types and Communication Modes Data Flow 

22 The following tables 2-3 enumerate by message type and communications mode each 

23 of the allowable transactions and their responses. Items marked "N/A" in the comment 

24 column will not be implemented in PDM2000 and are included here only for sake of 

25 completeness. 
26 

27 TABLE 2 - PDM TO SERVER 

28 

29 MSG COMM TRAN 

30 TYPE MODE CODE RESPONSE COMMENT 

31 

32 DataPostSet (PDM to Server) 

33 Cont N/A* 

34 Stop N/A* 
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1 More ACK/NAK 

2 None ACK/NAK 

3 Post scheduled sensor data 

4 Post requested sensor data 

5 Post exception sensor data 

6 Post scheduled messaging response 

7 Post requested messaging response N/A* 

8 Post protocol and messaging profile block 

9 Protocol settings 

1 0 Messaging profile settings 

11 CRC 

12 Post operational mode and status 

13 Post non-profile device settings N/A* 

14 Post call statistics N/A* 

1 5 Post exception other data (multiple types) e.g. profile failed 

1 6 Post scheduled sensor data failure 

1 7 Post requested sensor data failure 

1 8 Post scheduled messaging item failure 

19 Post requested messaging item failure N/A* 

20 (Note: Alarms not in COPD) 
21 

22 Inquiry (PDM to Server) 

23 Cont InstructionSet 

24 Stop N/A* 

25 More N/A* 

26 None N/A* 

27 Inquiry transaction 

28 (Note: PDM never sends an Inquiry if it has data to send itself) 
29 

30 ACK - Message Confirmation - (PDM to Server) 

3 1 Cont InstructionSet Response to InstructionSet + 

32 More 

33 Stop N/A* 
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1 




More ACK + Cont 


PDM now has data to send 


2 




None Goodbye 


Response to InstructionSet + 


3 


None 






4 

c 




Confirmation transaction 




J 
6 


XT A TT 

NAK- 


Message Failure - (PDM to Server) 




7 




Cont Resend message 


Try to resend reference message 


8 




Stop ACK + More / ACK + None 


Stop sending reference message 


9 






Server checks for other messages 


10 




More ACK + Cont 


PDM now has data to send 


11 




None 


N/A* 


12 




Failure transaction 




13 




(Note: Error information is in Transaction Value) 


1 A 

14 








15 


Goodbye (PDM to Server) 




16 




Cont 


N/A* 


17 




Stop Goodbye 


End message session 


18 




More 


N/A* 


19 




None 


N/A* 


20 




Goodbye transaction 




21 








22 




TABLE 3 - SERVER TO PDM 


23 








24 


MSG 


COMM TRAN 




25 


TYPE 


MODE CODE 


RESPONSE COMMENT 


26 








27 


InstructionSet (Server to PDM) 




28 




Cont 


N/A* 


2y 




Stop 


N/A* 


30 




More ACK/NAK 




31 




None ACK/NAK 




32 




Set protocol and messaging profile block 


33 




Protocol settings 
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1 

1 




Messaging profile settings 




o 




CRC 




j 




Send protocol and messaging profile block 


4 




Send requested sensor data 




5 




Perform requested messaging item 


N/A* 


6 

\j 




Set non-profile device settings 


N/A* 


7 




Send non-profile device settings data 


N/A* 


s 




Set operational mode & current status 




o 




Send operational mode & current status 




10 




Set call statistics (reset) 


N/A* 


1 1 
1 1 




Send call statistics 


N/A* 






Set no server message pending 


Server has no messages to send 










14 


ACK - Message Confirmation (Server to PDM) 




1 j 


Cont 


DataPostSet 


Response to DataPostSet + More 


16 


Stop 




N/A* 


17 

1 / 


More 


Inquiry (usually) 


Response to DataPostSet + None 


18 






Server has messages 


1Q 


None 


Goodbye (usually) 


Response to DataPostSet + None 


20 






Server has no messages 


91 




Confirmation transaction 








(Note: PDM ends all sessions. Server interrupt not used) 










94 


NAK - Message Failure (Server to PDM) 




25 


Cont 




N/A* 


26 


Stop 




N/A* 


97 


More 


Resend message or Stop 


Server has messages 


28 


None 


Resend message or Stop 


Server has no messages 


29 




Failure transaction 




30 




(Note: Error information is in Transaction Value) 


1 1 








32 


Goodbye (Server to PDM) 




33 


Cont 


No response required 


Normal end of message session 
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1 Stop N/A* 

2 More N/A* 

3 None N/A* 

4 Goodbye transaction 

5 (Note; PDM ends all sessions. Server interrupt not used) 
6 

7 Although, in a typical embodiment, the PDM of the present invention will be patient- 

8 worn and will monitor sensors attached to the patient, the PDM can also interface external 

9 devices that a patient can interact with for sensing medically relevant data, such as blood 

10 glucose monitors, scales, etc. The PDM can interface with these external devices in any 

1 1 known manner, such as by a wired connection that plugs in to the PDM or by wireless means, 

12 such as Bluetooth, IrDA, and IEEE 802. 1 1 protocols. 

13 In a basic embodiment, voice communication capabilities and the PSTN link can be 

14 omitted. In another embodiment, voice communications can be provided between the patient 

15 and caregiver by voice-over-IP technology in order to eliminate the PSTN link. 

16 A Wireless Internet Bio-telemetry Monitoring System has now been illustrated. It is 

17 important to note that, while a particular wireless protocol was described in the preferred 

18 embodiment (i.e., CDMA) this is not meant as a limitation. For example, other protocols for 

19 communication in a wireless network (such as a GSM, PCS or TDMA) will be equally 

20 suitable for use with the present invention. It is also anticipated that other types of wireless 

21 networks will also be suitable, such as satellite networks and wireless local loop networks. 

22 The requirement is that there be two-way communication with the PDM and that Internet 

23 connectivity flow as part of the communication system to allow interaction between health 

24 care provider and the patient via voice and via the Internet. It will be apparent to those 

25 skilled in the art that other variations in, for example and without limitation, the type of 

26 network, the type of bio-sensor, and the configuration of the patient monitor can be 

27 accomplished without departing from the scope of the invention as disclosed. 
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1 We claim: 

2 1 . A system for remotely monitoring patient variables comprising: 

3 at least one sensor means for acquiring medically relevant data from a 

4 patient; 

5 a patient-wearable monitoring unit connected to the sensor; 

6 said patient-wearable monitoring unit comprising a processor and further 

7 comprising 

8 a wireless communication device connected to a first wireless network, 

9 wherein said first wireless network is adapted to send and receive 

1 0 communications over the Internet; 

1 1 a Host data archive connected to the Internet to communicate with the 

12 patient-worn monitoring unit; 

13 a medical care provider terminal means connected to the second 

14 network for communication in a bi-directional manner between a medical care 

1 5 provider and the patient-worn monitoring unit over said first network. 

16 2. The system for remotely monitoring patient variables of claim 1 wherein the 

17 communication with the patient worn monitoring unit is bi-directional data 

18 communication. 

19 3 . The system for remotely monitoring patient variables of claim 1 wherein the 

20 communication with the patient worn monitoring unit is bi-directional voice 

21 communication. 

22 4. The system for remotely monitoring patient variables of claim 1 wherein the at 

23 least one sensor is a patient-worn multi-variable patient monitor. 

24 5. The system for remotely monitoring patient variables of claim 2 wherein the 

25 bi-directional data communication further comprises instructions from the 

26 medical care provider terminal to change configurable program instructions in 

27 the processor of the patient worn monitoring unit. 

28 6. The system for remotely monitoring patient variables of claim 5 wherein the 

29 instructions to change configurable program instructions comprises 

30 instructions to change alarm limits. 

31 7. The system for remotely monitoring patient variables of claim 5 wherein the 

32 instructions to change configurable program instructions comprises 
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1 instructions to change data collection parameters for the at least one patient 

2 worn sensor. 

3 8. The system for remotely monitoring patient variables of claim 3 wherein the 

4 bi-directional voice communications comprises voice-over-IP communications 

5 with a medical care provider professional 

6 9. The system for remotely monitoring patient variables of claim 8 wherein the at 

7 least one sensor is a patient-worn multi-variable patient monitor and further 

8 comprises a microphone and a speaker for transmitting voice communications. 

9 10. f The system for remotely monitoring patient variables of claim 3, further 

10 comprising a second network connected to said first wireless network and said 

1 1 medical care provider terminal means to transmit bi-directional voice 

12 communications. 

13 11. The system for remotely monitoring patient variables of claim 1 0 wherein the 

1 4 second network is a PSTN. 

15 12. The system for remotely monitoring patient variables of claim 1 wherein said 

16 at least one sensor is wirelessly connected to said patient-wearable monitoring 

17 unit. 

18 13. The system for remotely monitoring patient variables of claim 1 wherein said 

19 at least one sensor is a device for monitoring physiologic, biochemical or 

20 biometric variables. 

21 14. The system for remotely monitoring patient variables of claim 1 wherein 

22 the processor of the patient-worn monitoring unit further comprises a 

23 conversion means for adapting data transmission for multiple platforms, 

24 1 5. The system for remotely monitoring patient variables of claim 14 wherein the 

25 conversion means adapts data transmission for CDMA Periodic Post, CDMA 

26 Host Request, and RS232 Slave Request platforms. 

27 16. The system for remotely monitoring patient variables of claim 1 further 

28 comprising a Host server connected to the Internet for communicating with the 

29 patient-wearable monitoring unit and the medical care provider terminal in a 

30 bi-directional manner. 

31 17. The system for remotely monitoring patient variables of claim 16 wherein the 

32 patient-wearable monitoring unit includes instructions to post data to the Host 

33 server at a web site. 
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1 18. The system for remotely monitoring patient variables of claim 1 6 wherein the 

2 Host server includes instructions to initiate a voice call to a specific patient- 

3 wearable monitoring unit. 

4 19. The system for remotely monitoring patient variables of claim 16 including 

5 means for the patient to initiate a voice call to a medical care provider. 

6 20. The system for remotely monitoring patient variables of claim 16 including 

7 means for the patient to initiate a voice call to 911. 

8 21. The system for remotely monitoring patient variables of claim 1 wherein the 

9 patient-wearable monitoring unit is connected to a personal computer and the 

1 0 personal computer is connected to the Internet. 

1 1 22. The system for remotely monitoring patient variables of claim 2 1 wherein a 

12 service computer is connected to the Internet and includes software to perform 

13 testing and repair of the patient-wearable monitoring unit over the second 

14 network. 

15 23 . The system for remotely monitoring patient variables of claim 22 wherein the 

1 6 service computer includes instructions to download software programs to the 

1 7 patient-wearable monitoring unit over the Internet. 

1 8 24. The system for remotely monitoring patient variables of claim 1 6 wherein the 

19 conversion means adapts data transmission for multiple platforms in an 

20 encrypted format. 

21 25. The system for remotely monitoring patient variables of claim 16 wherein the 

22 Host server includes instructions to periodically retrieve continuous real-time 

23 waveform data from the patient-wearable monitoring unit. 

24 26. , The system for remotely monitoring patient variables of claim 16 wherein the 

25 patient-wearable monitoring unit includes instructions to store and execute an 

26 operating profile. 

27 27. The system for remotely monitoring patient variables of claim 26 including 

28 means for the operating file to be downloaded from the Host server. 

29 28. The system for remotely monitoring patient variables of claim 26 wherein the 

30 operating file further comprises a control block assigning time periods and 

3 1 cycles for each monitored patient variable. 
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1 29. The system for remotely monitoring patient variables of claim 26 wherein the 

2 operating file further comprises an enable/disable instruction for each 

3 monitored patient variable. 

4 30. The system for remotely monitoring patient variables of claim 1 6 wherein the 

5 patient-wearable monitoring unit includes an operational mode. 

6 31. The system for remotely monitoring patient variables of claim 30 wherein the 

7 operational mode is selected from the group consisting of; Idle Mode, Active 

8 Mode, Alarm Mode, and Event Mode. 

9 32. The system for remotely monitoring patient variables of claim 1 6 wherein the 

10 patient- wearable monitoring unit includes instructions to store internal status 

1 1 indicators of the patient-wearable monitoring unit at all times. 

12 33. The system for remotely monitoring patient variables of claim 32 further 

13 comprising the internal status indicators of measurement status, alarm status, 

14 alert status current operation mode, current operating profile, communication 

15 signal status, and memory status. 

16 34. The system for remotely monitoring patient variables of claim 1 wherein the 

17 processor includes logic and instructions to set an Alarm mode. 

18 35. The system for remotely monitoring patient variables of claim 34 wherein the 

19 processor sets the Alarm mode when a measurement exceeds set limits. 

20 36. The system for remotely monitoring patient variables of claim 1 wherein the 

2 1 patient-wearable monitoring unit includes instructions to contact the Host, 

22 which in turn includes instructions to contact the medical care provider in 

23 response to an Alarm mode being set. 

24 37. The system for remotely monitoring patient variables of claim 34 wherein the 

25 processor sets the Alarm mode when a measurement is not received by the 

26 Host server. 

27 38. The system for remotely monitoring patient variables of claim 8 wherein voice 

28 messaging is assigned priority by the processor according to the type of 

29 message being sent. 

30 39. The system for remotely monitoring patient variables of claim 1 6 including a 

3 1 power management program for execution by the processor. 

32 40. The system for remotely monitoring patient variables of claim 16, further 

33 comprising a touchscreen on said patient-wearable monitoring unit and 
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1 instructions for said processor to provide bi-directional text messaging 

2 ' between said patient-wearable monitoring unit and said Host server. 

3 4 1 . A method for remotely monitoring patient variables comprising: 

4 supplying a patient with a patient a patient-wearable monitoring unit 

5 connected to at least one sensor; wherein the patient-wearable monitoring unit 

6 includes a processor and further includes a wireless communication device to 

7 connect to a first wireless network; 

8 the monitoring unit sending and receiving communications with the 
• 9 first wireless network; and 

1 0 the wireless network sending and receiving communications from a 

1 1 medical care provider over the Internet so as to communicate in a bi- 

1 2 directional manner with the monitoring unit over first network. 

13 42. The method for remotely monitoring patient variables of claim 4 1 wherein the 

14 communication with the monitoring unit is bi-directional data communication. 

15 43 . The method for remotely monitoring patient variables of claim 4 1 wherein the 

1 6 communication with the monitoring unit is bi-directional voice 

17 communication selected from voice-over-DP via the Internet or voice 

1 8 communication over a second network between said first wireless network and 

1 9 the medical care provider. 

20 44. The method for remotely monitoring patient variables of claim 43 wherein 

2 1 said second network is a PSTN. 

22 45. The method for remotely monitoring patient variables of claim 4 1 wherein 

23 said at least one sensor is a patient-worn multi-variable patient monitor. 

24 46. The method for remotely monitoring patient variables of claim 42 wherein the 

25 bi-directional data communication is from a medical care provider terminal 

26 and changes configurable program instructions in the processor of the 

27 monitoring unit. 

28 47. The method for remotely monitoring patient variables of claim 46 wherein the 

29 change to configurable program instructions comprises instructions to change 

30 alarm limits or data collection parameters. 
31 
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1 48. The method for remotely monitoring patient variables of claim 45 wherein 

2 said at least one sensor further comprises a microphone and a speaker used for 

3 transmitting voice communications. 

4 49. The method for remotely monitoring patient variables of claim 41 further 

5 comprising wirelessly connecting said at least one sensor to said monitoring 

6 unit. 

7 50. The method for remotely monitoring patient variables of claim 41 further 

8 comprising selecting said at least one sensor from devices for monitoring 

9 physiologic, biochemical or biometric variables. 

10 51. The method for remotely monitoring patient variables of claim 4 1 wherein the 

1 1 processor of the monitoring unit further adapts data transmission for multiple 

12 platforms. 

13 52. The method for remotely monitoring patient variables of claim 5 1 wherein the 

14 multiple platforms are CDMA Periodic Post, CDMA Host Request, and 

1 5 RS232 Slave Request platforms. 

16 53. The method for remotely monitoring patient variables of claim 41 further 

1 7 comprising connecting a Host server to the second network for communicating 

18 with the monitoring unit and a medical care provider terminal in a bi- 

19 directional mariner. 

20 54. The method for remotely monitoring patient variables of claim 53 wherein the 

2 1 monitoring unit posts data to the Host server at a web site. 

22 55. The method for remotely monitoring patient variables of claim 53 wherein the 

23 Host server initiates a voice call to a specific monitoring unit. 

24 56. The method for remotely monitoring patient variables of claim 53 wherein the 

25 patient initiates a voice call to a medical care provider. 

26 57. The method for remotely monitoring patient variables of claim 53 wherein the 

27 patient initiates a voice call to 9 1 1 . 

28 58. The method for remotely monitoring patient variables of claim 41 further 

29 comprising connecting the monitoring unit to a personal computer and the 

30 personal computer to the Internet. 

3 1 59. The method for remotely monitoring patient variables of claim 58 further 

32 comprising connecting a service computer to the Internet and performing 

33 testing and repair of the monitoring unit over the second network. 
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1 60. The method for remotely monitoring patient variables of claim 59 wherein the 

2 service computer downloads software programs to the monitoring unit over 

3 the Internet. 

4 61 . The method for remotely monitoring patient variables of claim 53 wherein the 

5 processor adapts data transmission for multiple platforms in an encrypted 

6 format. 

7 62. The method for remotely monitoring patient variables of claim 53 wherein the 

8 Host periodically retrieves continuous real-time waveform data from the 

9 monitoring unit. 

10 63. The method for remotely monitoring patient variables of claim 53 wherein the 

1 1 monitoring unit stores and executes an operating profile. 

12 64. The method for remotely monitoring patient variables of claim 63 wherein the 

1 3 operating file is downloaded from the Host server. 

14 65. The method for remotely monitoring patient variables of claim 63 wherein the 

1 5 operating file further includes a control block assigning time periods and 

1 6 cycles for each monitored patient variable. 

1 7 66. The method for remotely monitoring patient variables of claim 63 wherein the 

1 8 operating file further includes an enable/disable instruction for each monitored 

19 patient variable. 

20 67. The method for remotely monitoring patient variables of claim 53 further 

21 comprising setting the monitoring unit to an operational mode. 

22 68. The method for remotely monitoring patient variables of claim 67 wherein the 

23 operational mode is selected from the group consisting of: Idle Mode, Active 

24 Mode, Alarm Mode, and Event Mode. 

25 69. The method for remotely monitoring patient variables of claim 53 wherein the 

26 monitoring unit stores internal status indicators of the monitoring unit at all 

27 times. 

28 70. The method for remotely monitoring patient variables of claim 69 further 

29 comprising storing the internal status indicators of measurement status, alarm 

30 status, alert status current operation mode, current operating profile, 

3 1 communication signal status, and memory status. 

32 71. The method for remotely monitoring patient variables of claim 4 1 wherein the 

33 processor sets an Alarm mode. 

42 



WO 02/067122 PCT/US02/04369 

1 72. The method for remotely monitoring patient variables of claim 71 wherein the 

2 processor sets the Alarm mode when a measurement exceeds set limits. 

3 73. The method for remotely monitoring patient variables of claim 41 wherein the 

4 monitoring unit contacts the Host server, which in turn contacts the medical 

5 care provider in response to an Alarm mode being set. 

6 74. The method for remotely monitoring patient variables of claim 73 wherein the 

7 processor sets the Alarm mode when a measurement is not received by the 

8 Host server. 

9 75 . The method for remotely monitoring patient variables of claim 43 wherein 

1 0 voice messaging is assigned priority by the processor according to the type of 

1 1 message being sent. 

12 76. The method for remotely monitoring patient variables of claim 53 wherein the 

1 3 processor executes a power management program. 

14 77. The method for remotely monitoring patient variables of claim 53, further 

1 5 comprising providing a touchscreen on said monitoring unit and instructions 

16 for said processor to provide bi-directional text messaging between said 

1 7 monitoring unit and said Host server. 

18 78. A system for remotely monitoring patient variables, comprising: 

19 at least one patient-worn sensor; 

20 a patient-worn monitoring unit connected to the sensor; 

21 said patient-worn monitoring unit comprising a processor and further 

22 comprising 

23 a wireless communication device connected to a first wireless network, wherein said 

24 first wireless network is adapted to send and receive communications over the 

25 Internet; 

26 a Host data archive connected to the Internet to communicate with the patient- 

27 worn monitoring unit; 

28 a second network connected to the Internet and first wireless network; 

29 a terminal means connected to the second network for communication in a bi- 

30 directional manner between a medical care provider and the patient-worn monitoring 

3 1 unit over said second and first networks. 
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1 


79. 


The system for remotely monitoring patient variables of claim 78, wherein the 


2 




communication with the patient-worn monitoring unit is bi-directional data 


3 




communication. 


4 


80. 


The system for remotely monitoring patient variables of claim 78 wherein the 


5 




communication with the patient-worn monitoring unit is bi-directional voice 


6 




communication. 


7 


81. 


The system for remotely monitoring patient variables of claim 79 wherein the 


8 




bi-directional data communication further comprises instructions from the 


9 




health care provider terminal to change configurable program instructions in 


10 




the monitoring unit processor. 


11 


82. 


The system for remotely monitoring patient variables of claim 81 wherein the 


12 




instructions to change configurable program instructions comprises 


13 




instructions to change alarm limits. 


14 


83. 


The system for remotely monitoring patient variables of claim 81 wherein the 


15 




instructions to change configurable program instructions comprises 


16 




instructions to change data collection parameters for the at least one sensor. 


17 


84. 


The system for remotely monitoring patient variables of claim 80 wherein the 


18 




bi-directional voice communications comprises voice communications with a 


19 




health care provider professional. 


20 


85. 


The system for remotely monitoring patient variables of claim 84 wherein the 


21 




sensor further comprises a microphone for allowing voice communications. 


22 


86. 


The system for remotely monitoring patient variables of claim 85 wherein bi- 


23 




directional voice communications occurs via the microphone and a speaker 


24 




contained in the patient-worn monitoring unit. 


25 


87. 


The system for remotely monitoring patient variables of claim 78 wherein the 


26 




second network is a PSTN. 


27 


88. 


The system for remotely monitoring patient variables of claim 78 wherein the 


28 




sensor is a bio-sensor. 


29 


89. 


A method for remotely monitoring patient variables, comprising: 


30 




attaching at least one patient-worn sensor to a patient; 


31 




providing a patient-worn monitoring unit connected to the sensor, wherein 


32 


said patient-worn monitoring unit includes a processor and a wireless communication 


33 


device connected to a first wireless network; 
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1 said patient-worn monitoring unit sending and receiving communications over 

2 the Internet via said first wireless network; 

3 providing a Host data archive connected to the Internet to communicate with 

4 the patient-worn monitoring unit; 

5 connecting a second network to the Internet and said first wireless network; 

6 connecting a terminal to the second network for communication in a bi- 

7 directional manner between a medical care provider and the patient-worn monitoring 

8 unit over said second and first networks. 

9 90. The method for remotely monitoring patient variables of claim 89, wherein the 

10 communication with the patient-worn monitoring unit is bi-directional data 

1 1 communication. 

12 91 . The method for remotely monitoring patient variables of claim 89, wherein the 

13 communication with the patient-worn monitoring unit is bi-directional voice 

14 communication. 

15 92. The method for remotely monitoring patient variables of claim 90, wherein the 

16 bi-directional data communication sends instructions from the health care 

17 provider terminal to change configurable program instructions in the 

1 8 monitoring unit processor. 

19 93. The method for remotely monitoring patient variables of claim 92, wherein the 

20 instructions sent to change configurable program instructions change alarm 

21 limits. 

22 94. The method for remotely monitoring patient variables of claim 92, wherein the 

23 instructions sent to change configurable program instructions change data 

24 collection parameters for the at least one sensor. 

25 95. The method for remotely monitoring patient variables of claim 9 1 , wherein the 

26 bi-directional voice communications send and receive voice communications 

27 with a health care provider professional. 

28 96. The method for remotely monitoring patient variables of claim 95, further 

29 comprising providing a microphone for allowing voice communications. 

30 97. The method for remotely monitoring patient variables of claim 96, further 

3 1 comprising using the microphone and a speaker contained in the patient-worn 

32 monitoring unit to provide bi-directional voice communications. 
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98. The method for remotely monitoring patient variables of claim 89, wherein the 
second network is a PSTN. 

99. The method for remotely monitoring patient variables of claim 89, wherein the 
sensor is a bio-sensor. 
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